Petter's Blog

From Slashdot’s Blizzcon interview:

We have certain algorithms in place that will attempt to analyze data and see what the player is doing. One thing that we are doing this time around that is totally new — our AI cheated in the past. Starcraft and Warcraft III saw the whole map, so the AI could see what the player was building or doing at any given time. The AI in Starcraft 2 now has to scout, and it's much harder to do, but there is a pretty effective AI in there for now.

Chris Sigaty (Lead Producer, Starcraft 2)

I have had a seriously life-altering experience and have some work to do in terms of redefining who I am.

It‘s all good.

(05:19:55 PM) David: another case of PHP informing me of nothing - i'm using file_put_contents only I had the params filename and the filecontent mixed... do I get an error msg... NOOooOooooO
(05:21:06 PM) Petter: Of course not. It might upset you to get error messages.
(05:25:38 PM) David: It should be called 'Delusional Programming'
(05:26:53 PM) Petter: Programming With Never-Ending Denial
(05:26:59 PM) Petter: (note handy acronym)

John McCain is a little too honest for his own good.

What is your maiden name? What is your favourite colour? How easy do you want to make it for people who’ve read your blog to steal your data?

This sort of thing seems to be discussed a lot recently, especially in the wake of Sarah Palin’s email account getting hacked, but I’ve seen a few other recent mentions of this lame attempt at security, in two different incarnations:

1. Password retrieval: Instead of emailing a temporary password to your registered email address, ask a question like the above
2. A piss-poor attempt at two-factor security: Ask a question in addition to a proper password

I don’t think I need to talk in-depth about why both cases are bad ideas—these security questions are invariably so much easier to crack than even a half-arsed password that they are, at best, a nuisance and no help at all, and at worst a serious liability.

When I can (id est, when it’s used for retrieval purposes only and not asked in addition to real password, as my bank unfortunately does), I tend to claim that my first pet was named sdfjgokis89u89u23nm or that I grew up on 15 lksjdf9)()*klasdjfdfsfsdlkj Street, or similar. I keep track of my passwords. There are good ways of doing so.

He can debate himself just fine:

Besides the obvious (id est, the people listing me as a friend on LiveJournal), who’s actually reading this blog?

I recently received an email from an acquaintance, whom I shall not name here, on the subject of allergies (people who know me tend to bring that subject up now and then). Anything I represent as a quote below will actually be a paraphrase either to clarify or to disguise certain characteristic writing traits.

Here follows a snippet from the first email in our exchange:

Here is one of the articles (I find it very interesting):
http://www.healingdaily.com/detoxification-diet/enzymes.htm

This is from there:

It was found that after a person eats cooked food, his/her blood responds immediately by increasing the number of white blood cells. This is a well-known phenomena called 'digestive leukocytosis', in which there is a rise in the number of leukocytes - white blood cells - after eating.

Since digestive leukocytosis was always observed after a meal, it was considered to be a normal physiological response to eating. No one knew why the number of white cells rises after eating, since this appeared to be a stress response, as if the body was somehow reacting to something harmful such as infection, exposure to toxic chemicals or trauma.

Apart from the fact that the authors of the website do not know that phenomena is the plural form of the noun, we can’t learn a whole lot from this, but the briefest of perusals of the website demonstrates it to be a hotbed of quackery, some of it dangerous. As I said in my initial reply,

That website is, unfortunately, full of shit. Some of it is actually very dangerous. Chelation -- which they seem to think is just *great* -- is a favourite of alternative medicine people, but it's a terrible idea.

[I’m snipping a lot of stuff here—if you want to know what I think about chelation, ask.]

…chelation therapies are toxic. […] Another interesting fact is that […] chelation therapy will leech [sic] calcium from your body and may lead to hypocalcemia. This can cause you to stop breathing or cause cardiac arrhythmia, in really bad cases…

…I won't take my medical advice from people I *know* to be full of shit.

I consider this a useful caveat—the website contains stuff that makes sense to me, but that doesn’t prevent some of it from being shit, and as a single source it’s therefore useless.

Now, the problem is that although the website, in all fairness, does contain a reasonable description of what an allergy is, my acquaintance took away something rather different, judging from my acquaintance’s reply, email #3 in the sequence:

The whole point is that by eating properly, and giving your body the food it will be happy with, and not junk it with stuff such as doughnuts, dead burgers, and cooked tasty food (just because we like it), you will strengthen the natural fighting mechanism of your body, which is not now fuctioning properly in most humans, because it is always busy fighting dead food.

There is a terrible irony here, because an allergic reaction is an immune response—an immune response to what I call spurious pathogens, which is my trumped-up way of saying it’s triggered by the wrong things; when I go into anaphylactic shock from exposure to peanut butter, it’s because my immune system thinks I’ve taken poison and is doing all it can to rid me of it (unfortunately killing me in the process). The immune system is therefore not too weak in a person with allergies; it’s responding too strongly!

In fact, some very interesting research has generated the hypothesis that the reason why allergies are so prevalent in the hypersanitised Western nation is because we are, in a sense, too healthy. Carl Zimmer describes this beautifully in his book Parasite Rex. The brief gist of it (as I understand it) is that our immune system helps us fight off viruses, bacteria, and parasites in general. Therefore, parasites have evolved mechanisms to suppress our immune system. In response, evolution comes to supercharge our immune system to cope with the parasites’ chemical weaponry; they escalate in turn…and so on, for a few million years, until modern living virtually eliminates whole arrays of parasites and leaves us with supercharged immune systems without the dose of immunosuppressants they would normally be hampered by. Hence, it may be, they go haywire.

And this isn’t just crazy talk. It’s real science, and experiments have been performed, including one study (also here) where test subjects were deliberately infected with (controlled doses of) hookworms, and experienced relief of allergy symptoms.

There’s a kind of terrible backwardness throughout this entire discussion so far, such as when my sparring partner in discussion asks

Would you rather eat dead but safe food, or live and energetic (perhaps with traces of nature's dark side as parasites)?

Need I mention that the most energetic of foods are ones high in quick carbohydrates, simple sugars, and fats? Need I point out that vegetables are good for you not because they are energetic, but specifically because they are low in energy density? Apparently I do. As for the dark side…

The ironic thing is that this person and I could probably largely agree on what constitutes a healthy diet, but the mode of thinking is completely different. But then, I do not generally engage in debate to dispute (specifically) a conclusion, but rather flaws in reasoning. Any foolish way of thinking may lead you accidentally to the right answer, but relying on it is dangerous. This is the same thing that leads to other alternative medicine treatments—I will not use the word cures to describe them. Alternative medicine kills. (Chelation therapy can certainly kill.) Detoxification and colon cleansing kill, too. Even raw food diets have ended up killing people—children—when people failed to apply critical thought.

That is why I am proud to consider myself a skeptic, and that is why I will never abide terrible reasoning, even when no conclusions have ended up catastrophic—yet.

This is chiefly for my own benefit, because writing things down helps you remember them (even if you don’t consult the notes).

Today I was practicing a new move with a guy…a bit taller than me, but skinnier, probably no vast weight difference. We’re fairly evenly matched, but I had a much easier time with this particular, new half-guard sweep, with which we were both unfamiliar.

It occurred to me that while it comes naturally to break a technique down into its constituent parts—break balance to one side with a fake scissor sweep; pass your opponent’s posting arm over to the other side; roll him onto your shins; roll backwards over your shoulder, sweeping him—and while there is some sense in thinking about it that way, and certainly teaching it that way—it doesn’t make sense to do it that way, even when practicing.

What has to be kept in mind is that this sweep (like all the throws and sweeps I’ve learned so far) really have two parts: First get your opponent off balance, or force him to load his weight precariously; then capitalise on the imbalance you’ve created to execute a technique. But this has to flow; it makes no sense to unbalance a person only to give him a moment to recover his balance (perhaps unconsciously) while you think about the next step!

Additionally, a lot of these techniques have a momentum that carries through if you perform them smoothly (in pace, not necessarily skill), and by breaking them up. Into. Discrete. Steps. That momentum is lost. My training parter failed (at first) to do the sweep because he took his time and thought about each step; I succeeded (at once) because I tried to do it slowly and methodically but continuously.

Some techniques can be broken up into discrete steps (though they tend to work a lot better when you do them smoothly!), but that requires you to control the opponent throughout—and if the technique relies on momentum or unbalancing, it makes no sense to try.

…Particularly when you’re never quite sure whether some function or object expects (or returns) local or UTC time, and when your database uses at least three different formats for storing them. (I officially hate timezones, and will let this be a reminder never to use anything but UTC for storing dates in an application, ever.)

Subject: The time box issue/GM date problem

I *think* I finally fixed it -- please test and verify. (I checked the
configuration tab, which seems to behave properly; I verified that the
profile displays matched, and I verified that saving a time returns the
same time rather than an off-by-an-hour one.)

That was an incredibly irritating bug, and I missed two jiu-jitsu
practices over it, but I introduced it by making a bad assumption, so I
suppose that's fair.

My bad assumption was that I could take a time T, take its timezone
offset, and by adding (hours*3600+minute*60+seconds) and adding the
offset back, I'd get a good time. That was stupid.

The problem is that different timestamps, from different dates, come
back with different timezone offset. I would suspect this may have to do
with policy changes in things like timezones and DST. Specifically, the
timezone offset from UTC on the same machine differs by 3600 seconds --
one hour -- for timestamps in 1970 and timestamps in 2008, respectively.

On the bright side (and the reason why I made those changes in the first
place), we can now say things like

	$d->toTimestamp()

instead of

	date('G', $time_inseconds)*3600
	         +$minutes_default*60
	         +$seconds_default;

which I think is worth it in the long run. Or so I tell myself to
console myself for the two missed jiu-jitsu practices.

-- 
Petter Häggholm
eRezLife Software
http://www.faqs.org/docs/jargon/T/top-post.html

Since Internet Explorer is completely incapable of accepting the proper Content-type for XHTML, application/xhtml+xml, and since you should never send XHTML 1.1 as text/html, I decided to change my website from XHTML 1.1 to XHTML 1.0 Strict. I didn’t really have to change anything besides the DOCTYPE, so it was a very small deal—small enough that even I can be bothered to do that much to accommodate Internet Explorer (p.b.u.i).

However, this just meant that I could legitimately send a content-type of text/html, which IE understands. It didn’t mean that my site worked in IE, and in fact, it did not.

It turns out that IE has a really, really stupid parsing bug—I cannot call it anything else. While you might easily imagine that anyone writing an X[H]TML parser would have a generic tag-parsing mechanism, where a <short_tag/> is just a <long_tag></long_tag> with an empty (perhaps null) content field. That’s how I do it. Not, it appears, IE: IE cannot parse the tag <script src="…"/>. Easy fix, but who the hell would think to look for it? —This is, by the way, a bug not just in IE6, but also in IE7. I can only hope that they’ve fixed it in IE8.

Speaking of IE8, if anyone reading this has a copy of it, I’d be interested to hear how it renders my site as compared to IE7 and/or compared to another browser (Firefox or Opera—I know it works in those). In particular, I’m not sending data as text/html to IE8 at this point; until I know that it’s broken, I’ll give them the benefit of the doubt and treat them as a proper browser capable of dealing with modern web standards.

I read an interesting article by Joel Spolsky, In Defense of Not-Invented-Here Syndrome. It’s worth reading, but in case you're feeling lazy, here are the highlights:

When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.

[…]

The best advice I can offer:

If it's a core business function -- do it yourself, no matter what.

Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you're a pharmaceutical company, write software for drug research, but don't write your own accounting package. If you're a web accounting service, write your own accounting package, but don't try to create your own magazine ads. If you have customers, never outsource customer service.

Now, I absolutely agree with his best advice—if it’s a core business function, do it yourself. After all, it’s your business to perform core business functions well, and if you can’t (or don’t) do it better than your competitors, you don’t have a selling point. But to imply even loosely (he does take the edge off it slightly later in his article) that because you write software, all of software is your core business function, is, I think, so hyperbolic as to be completely misleading. The worst part of the article follows:

The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it's botched up. Yes, there are plenty of places like this. If you're in one of them, I can't help you.

How about an exception for when your people have better things to do? We use all kinds of libraries, internal and external. We use an external DB compatibility layer, various internal tag generation and Javascript DOM libraries, an internal ORM, an external email library with internal wrappers… According to the Spolsky logic, here, we should stick with the internal Javascript library, because our devs know our needs best (true); we should stick with the internal ORM; we should possibly even contemplate our own internal DB layer…this has in fact been brought up, and I think it’s a terrible idea.

Because, let’s face it, DB layers and fancy DOM manipulations are not our core business functions. Our core business functions are things like writing very flexible management systems for medical schools and university residences with client-defined workflows and customiseable forms and reports. This is what we do. This is what we sell. This is what our clients pay us to do, and what they cannot get from anyone else (at competitive prices).

This is why I think we should phase out our internal DOM stuff in favour of jQuery (which we recently adopted), why we should stick with MDB2 for a DB layer, and why I'd be happier if we had a third-party ORM. Is it because I think that the MDB2 people, the jQuery people, and the hypothetical ORM people are smarter than us, or better programmers? Not at all. It’s because that’s not what we’re paid to do, and unless the tools are really bad, it’s going to be vastly more productive to work with the third-party tools, find other third-party tools, or help fix the current tools, in some order of preference.

Maybe Microsoft can afford a team to make a custom compiler for Excel. We sure as hell can’t. We’ve got enough bugs and feature requests to worry about as it is, and almost none of them are ultimately the fault of any third-party library. (I’ve made three bug reports to the MDB2 project, I believe—I can assure you that we have rather more bugs than that in our tracker.)

Now, I’m sure that Joel Spolsky is a smart guy who knows all this, and may have known it before I first used a keyboard (there’s a reason I don’t send this as an email to Joel Spolsky). However, given all these ifs, buts, and general caveats, what’s the point of that article? If the real gist of the article, put succinctly and honestly, should be Not-Invented-Here Syndrome is not a valid concern for your company’s core competency, nor if adequate third-party solutions cannot be found or afforded, I think this is a job for…

Emphases added—I have nothing else to add.

The style I follow is to look at all the things the class should do and test each one of them for any conditions that might cause the class to fail. This is not the same as test every public method, which some programmers advocate. Testing should be risk driven; remember, you are trying to find bugs now or in the future. So I don't test accessors that just read and write a field. Because they are so simple, I'm not likely to find a bug there.

This is important because trying to write too many tests usually leads to not writing enough. I've often read books on testing, and my reaction has been to shy away from the mountain of stuff I have to do to test. This is counterproductive, because it makes you think that to test you have to do a lot of work. You get many benefits from testing even if you do only a little testing. The key is to test the areas that you are most worried about going wrong. That way you get the most benefit for your testing efforts.

It is better to write and run incomplete tests than not to run complete tests.

[…]

When do you stop [adding tests]? I'm sure you have heard many times that you cannot prove a program has no bugs by testing. That's true but does not affect the ability of testing to speed up programming. I've seen various proposals for rules to ensure that you have tested every combination of everything. It's worth taking a look at these, but don't let them get to you. There is a point of diminishing returns with testing, and there is the danger that by trying to write too many tests, you become discouraged and end up not writing any. You should concentrate on where the risk is. Look at the code and see where it becomes complex. Look at the function and consider the likely areas of error. Your tests will not find every bug, but as you refactor you will understand the program better and thus find more bugs. Although I always start refactoring with a test suite, I invariably add to it as I go along.

Martin Fowler, Refactoring

What we really need to do at work, however—or rather, what we need to figure out how to do, which is far from trivial as our bugs tend to rely on huge amounts of database state, some from clients that don't give us easy access to it:

…When I get a bug report, I begin by writing a unit test that causes the bug to surface. I write more than one test if I need to narrow the scope of the bug, or if there may be related failures. I use the unit tests to help pin down the bug and to ensure that a similar bug doesn't get past my unit tests again.

When you get a bug report, start by writing a unit test that exposes the bug.

Ibid.

I've launched a new version of my website. Although there are some content tweaks, the chief differences are

1. The backend—it used to be static HTML with a PHP page for the book list; now it's all dynamically created using mod_python.
2. It now uses jQuery for some fancy effects (and should fallback rather gracefully with clients that don't support, or have disabled, Javascript; except for the book list page—I still need to make a static version of that one). I'm particularly fond of the blog widget using that JSON dump.

The idiocy of anti-vaccine activists is now threatening the health and lives of people in my area. The general problem is fairly well described by a New York Times editorial (August 24):

There has been an upsurge of measles cases in the United States, mostly because of parents’ misguided fears of vaccinations. The number is still relatively small — but climbing. In the first seven months of this year, 131 cases were reported to the Centers for Disease Control and Prevention, more than during the same period in any year since 1996. No deaths were reported, but at least 15 patients were hospitalized.

Most people have forgotten, but measles was once an uncontrolled scourge that infected three million to four million Americans annually. Victims typically suffered a rash, fever and diarrhea, but severe cases could lead to pneumonia or encephalitis. In bad epidemic years, some 48,000 Americans were hospitalized, 1,000 more were chronically disabled, and 400 to 500 died.

Then the development of effective vaccines and compulsory vaccination of schoolchildren drove the disease to the sidelines. Health authorities declared that measles had been eliminated from the United States in 2000. Only a few score cases have been reported annually in recent years, mostly imported from abroad.

Nearly all of the outbreaks this year were triggered by a mere 17 travelers or foreign visitors who contracted the virus abroad. The alarming wrinkle this year is that, once the virus is imported, it seems to be spreading to more people than before.

Outbreaks have occurred among home-schooled children who escaped the compulsory school vaccinations, and among children whose parents oppose vaccination, for philosophical and religious reasons or fear that the combined measles, mumps and rubella vaccine is dangerous. Many fear that the vaccines cause autism, a theory that has been thoroughly debunked by multiple studies and by authoritative medical organizations.

Israel, Switzerland, Austria, Italy and Britain are reporting sizable outbreaks of measles among populations that have refused vaccination. Although vaccination rates remain high in this country, some experts fear that they may be starting to drop. Because it is so contagious, measles is one of the first diseases to reappear when immunization coverage declines. If confidence in all vaccines were to drop precipitously, many diseases would re-emerge and cause far more harm than could possibly result from vaccination.

I bet you have! I bet, furthermore, that you've wondered how to do it gracefully, especially with XHTML, which doesn't allow document.write() which is the only Javascript-based solution that LiveJournal offers out of the box.

Why do I want to use Javascript? Well, I could use a server-side script to extract the posts, but that's precisely the problem—it'll be serverside, and why should I make it so? Ultimately, the transaction is between the client and the LiveJournal server. There's no logical need for my webserver to fetch the contents, then paste and send the contents of the blog when the client is perfectly able to fetch it himself. Other solutions, like <iframe>s, are little less unsatisfying: They're ugly and break the page layout.

But how can I gracefully embed the blog in a webpage without document.write()? I thought for a while of various horrible schemes—could I, for instance, create a hidden <iframe> and extract its contents on page load? I'm still not sure if it's possible; it would certainly be cumbersome, and if it is possible it seems to expose the user to cross-site scripting attacks. (If it is possible, and if my <iframe> source referred to anyone else's LiveJournal, I could Ajax it right back to my server, hidden posts and all—because frame solutions use the client's cookies to determine privelege levels.)

The answer is here, it uses JSON, and it is customiseable, although it takes a wee bit of tweaking and (unfortunately) some poking at S2 layers. The credit belongs with slothman.

One of these days I'll actually stop tweaking the mod_python-based version of my website and launch it…

Dealing with a large volume of bugs in one day is kind of stressful—we got sixteen show-stopper bug reports today, half of which were duplicates, and all of which were initially blamed on my refactorings. Some of them were due to me (so I'm annoyed because I broke a few things), though I've fixed all those now; some of them were due to a bug no less than four years old (so I'm annoyed because I was initially blamed for things that were done years before I even started working here).

But what currently annoys me is that all of them were communicated to me poorly—in two massive emails with tons of irrelevant conversations cited rather than point-by-point, and all top posted (reply at the top, quoted message responded to at the bottom).

I realise that top posting is used by a huge number of people—probably the majority of non-geeks. It is nonetheless a terrible practice, because one of the following must be true:

• The quoted message is not needed for context, and its inclusion is redundant, making the email unnecessarily large. Since I don't know if there's anything important below, I have to scroll down to check just in case.
• The quoted message is needed for context. I have to scroll down to the middle of the email, read the quoted message, then scroll back up to read the reply. If it is a long email, I may have to scroll back and forth to keep track.

Here's what top-posting looks like. Note that when we start reading, we have no idea what is supposed to be a good idea unless we send so little email that the referent for the pronoun that is obvious.

Yes, I think that's a good idea. It makes it easier for me
to write, and I'm lazy.

-----Original Message-----
From: Petter Häggholm [mailto:petter@fake.com] 
Sent: August 27, 2008 7:12 PM
To: Top Poster
Subject: Something

Do you really think that top-posting is a good idea?
Why or why not?

What inline posting looks like:

Petter Häggholm wrote:
<
< Do you really think that top-posting is a good idea?

Of course not.

< Why or why not?

Not only does it force scrolling, it also makes it hard to
respond in a concise, point-by-point manner *inline* with
the message.

Honestly, I don't think top-posting is ever a good thing. The good alternative to bottom-posting (or inline posting) is to reply in such a comprehensive way that the quoted message is not necessary for context, and thus should not be included (if the sender wants to refer to it, he presumably has the power to keep it archived). This would entail writing an email like a regular letter—I do so on occasion, but that's not the nature of technical communication.

In The Fellowship of the Ring we are introduced to Strider:

Suddenly Frodo noticed that a strange-looking weather-beaten man, sitting in the shadows near the wall, was also listening intently to the hobbit-talk. He had a tall tankard in front of him, and was smoking a long-stemmed pipe curiously carved. His legs were stretched out before him, showing high boots of supple leather that fitted him well, but had seen much wear and were now caked with mud. A travel-stained cloak of heavy dark-green cloth was drawn close about him, and in spite of the heat of the room he wore a hood that overshadowed his face; but the gleam of his eyes could be seen as he watched the hobbits.

…

…What his right name is I've never heard, [said Butterbur,] but he's known round here as Strider. Goes about at a great pace on his long shanks; though he don't tell nobody what cause he has to hurry.

In the early draft versions, before Strider became Aragorn son of Arathorn heir to Isildur and the kings of Númenor, he appeared somewhat different, and (like Frodo) bore another name:

Suddenly Bingo noticed that a queer-looking, brown-faced hobbit, sitting in the shadows behind the others, was also listening intently. He had an enormous mug (more like a jug) in front of him, and was smoking a broken-stemmed pipe right under his rather long nose. He was dressed in dark rough brown cloth, and had a hood on, in spite of the warmth, – and, very remarkably, he had wooden shoes! Bingo could see them sticking out under the table in front of him.

…

…What his right name is I never heard, [said Butterbur,] but he's known round here as Trotter. You can hear him coming along the road in those shoes: clitter-clap – when he walks on a path, which isn't often.

(From The Return of the Shadow, volume VI of The History of Middle-earth.)

The fine print: I don't yet have my Permanent Resident Card; they're mailing it to me (six to eight weeks). However, I do have the permanent visa, which is legally equivalent. The only thing I can't do with this is go on international flights—commercial carriers ask to see the PR card. In every other respect, my visa is legally equivalent to the PR card—I can stay in the country permanently, leave on trips and return, work for any employer, and so forth. And I'll have the PR card within the next two months, at which point I can go on international flights—home for Christmas, for instance!

The only real differences between my status and that of a citizen are that I cannot vote, and that my status can be revoked if I become involved in criminal activity, or if I spend less than two out of every five years in Canada—both of which conditions are hardly onerous, especially compared to previous restrictions (being tied to a specific employer, and with an expiry date on the visa).

Fine print aside, however, the chief point remains: After six years of living on temporary permits, bound to specific schools and jobs, I am free and I am officially a Permanent Resident of Canada.

Today, I received my Confirmation of Permanent Residence. This means that all my applications have gone through and have been approved, and all my fees have been paid.

For some silly reason, you can only get the final visa when you enter Canada—even if you are already in Canada, which means I need to leave and come back again (specifically, I need to cross a land border, so I have to go down to the US border, step across, and step back across), and show my documents and passport to an Immigration agent.

But never mind that. I'll have to somehow organise a strange little trip, hopefully very soon indeed (I'm thinking later this week if possible…which it may or may not be), but my application was granted, and within a matter of days, now, I should officially be a Permanent Resident of Canada.